home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19960425-19960715 / 000133_news@columbia.edu _Thu May 23 20:30:08 1996.msg < prev    next >
Internet Message Format  |  1996-07-26  |  4KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.35.159]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id UAA19408 for <kermit.misc@watsun>; Thu, 23 May 1996 20:30:07 -0400 (EDT)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.5/8.7.3) id UAA05799 for kermit.misc@watsun; Thu, 23 May 1996 20:30:04 -0400 (EDT)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: Best efficiency ?
  8. Date: 24 May 1996 00:29:56 GMT
  9. Organization: Columbia University
  10. Lines: 63
  11. Message-ID: <4o2vu4$5kf@apakabar.cc.columbia.edu>
  12. References: <4o08gj$d5u@ns2.ryerson.ca> <31a47d81.389121497@128.230.1.4> <TOM.96May23115142@amber.ssd.csd.harris.com>
  13. NNTP-Posting-Host: watsun.cc.columbia.edu
  14.  
  15. In article <TOM.96May23115142@amber.ssd.csd.harris.com>,
  16. Tom Horsley <Tom.Horsley@mail.hcsc.com> wrote:
  17. : Well, as long as people are on the subject, I'll mention a problem I'm
  18. : having (but I admit up front, I haven't tried nearly hard enough to track it
  19. : down yet).
  20. : 
  21. : I have the following path when attempting to download a file:
  22. : 
  23. : Windows NT 4.0 Beta <-> ZyXel <-> USR <-> Portmaster <-> firewall <-> Unix
  24. : (with K95)
  25. : 
  26. : I am transfering from the Unix box to the Windows NT box. The connection
  27. : is 8 bit clean all the way (I'm fairly positive of that).
  28. : 
  29. : When I issue all the commands from the FAQ to give me a fast, clean, max
  30. : throughput kind of connection and start the download it just screams for the
  31. : first few kilobytes, then (judging from the lights on my modem), someone
  32. : decides to do some RTS/CTS flow control signalling, and it comes to a dead
  33. : halt, sits there for several seconds, flashes the RTS/CTS lights, sends a
  34. : few more bytes, then flashes the RTS/CTS lights again, and sort of stays in
  35. : "dribble" mode for the rest of the file transfer.
  36. : 
  37. When you say you are downloading, that would seem to point the finger at NT
  38. as the flowcontrolmeister.  Stuff is coming in faster than NT can handle, so
  39. it says "stop" to the modem.  Why would it do that?  Certainly it's not
  40. because Kermit can't keep up, because Kermit can receive files at hundreds
  41. of K per second on a network connection (under ideal conditions) -- way
  42. faster than a modem.  So if NT is the culprit, then it's probably the serial
  43. port driver, the disk driver, or some combination.
  44.  
  45. The fact that Kermit receives a few K (four maybe?) before this starts seems
  46. to incriminate the disk driver more than anything else.  I don't pretend to
  47. be an NT expert, but it sounds like its disk output buffer filled up and it
  48. went to actually write the stuff out, and maybe it can't "walk and chew gum
  49. at the same time" (some of us are like that) so it told the serial driver to
  50. shut up the modem while it was writing.  Sort of like happens in DOS :-)
  51.  
  52. It also tends to exonerate the PC serial port and driver, since if the first
  53. few K did not make the PC interrupt itself to death, why should subsequent K?
  54.  
  55. So maybe there is something you can do by way of increasing disk-write
  56. buffers, or disk cache, or somesuch, or some other NT tuning ritual, that I
  57. will leave to the NT experts.
  58.  
  59. : Somewhere along the line, triggering flow control constipates some part of
  60. : my connection, but since the problem could be a bug in NT, or a bug in the
  61. : ZyXel or USR handling of flow control, or a problem with buffering or flow
  62. : control in the Portmaster, or the firewall, or the Unix box, I'm not sure
  63. : what to check or where to look. (And a DAT tape in the glove compartment of
  64. : my car on the way home is *much* higher bandwidth than kermit, so I don't
  65. : need to do file transfers very often, which is why I haven't spent much time
  66. : on trying to track this down :-).
  67. :
  68. "Never underestimate the bandwidth of a station wagon full of magnetic
  69. tapes", updated to more compact media (and perhaps also cars).  But yeah, it
  70. could be any of those things.  It could, for example, be some kind of
  71. "resonance" (and I mean that in bad way) between the modems, but that would
  72. not account for the computer's RTS signal going off.  And, to the best of
  73. my knowledge, NT's handling of RTS/CTS is, in itself, not buggy (unlike, say,
  74. Windows 95's handling of Xon/Xoff).  So your best bet is to start by looking
  75. into the disk subsystem and/or cache.
  76.  
  77. - Frank